X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C73A5C.7BDD1798@onstor-exch02.onstor.net>; Wed, 17 Jan 2007 09:25:29 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C73A5C.7BDD1798"
Content-class: urn:content-classes:message
Subject: RE: Kerberos functional spec
Date: Wed, 17 Jan 2007 09:25:29 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E028CFF@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Kerberos functional spec
thread-index: Acc168TKVL4+EE/8QdSEzxjEIj0VzAC7bJ+AAAkoRNAAKC+LwAAAjitwAABr/CAALjvTcQ==
References: <BB375AF679D4A34E9CA8DFA650E2B04E021855E9@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04E02185614@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04E0218561D@onstor-exch02.onstor.net>
From: "Shamsudeen Jeseem" <jeseem@onstor.com>
To: "Ron Bhanukitsiri" <ronb@onstor.com>,
	"Mary Li" <mary.li@onstor.com>,
	"Jonathan Goldick" <jonathan.goldick@onstor.com>,
	"Brian DeForest" <brian.deforest@onstor.com>,
	"dl-Design Review" <dl-designreview@onstor.com>
Cc: "Narayan Venkat" <narayan.venkat@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C73A5C.7BDD1798
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Few suggestion

1. can we have specific CLI to allow diag user to disable KRB =
authentication only. So that in case of error scenarios, the filer can =
be switched back to support NTLMv2 only auth.

2. unix/linux KDC ?=20
AFAIK there is no unix/linux KDC. Do you mean MIT KDC server ?
These may be used in mixed scenarios having both unix and windows pcs




Also a pointer ,=20
single sign-on is supported by KRB5 by using credential forwarding. So =
it should work.



3. Will filer login also be supported for KRB ?

-jes

-----Original Message-----
From: Ron Bhanukitsiri
Sent: Tue 1/16/2007 11:20 AM
To: Mary Li; Jonathan Goldick; Brian DeForest; dl-Design Review
Cc: Narayan Venkat; Ron Bhanukitsiri
Subject: RE: Kerberos functional spec
=20
Thanks Mary.

_____________________________________________
From: Mary Li=20
Sent: Tuesday, January 16, 2007 11:15 AM
To: Ron Bhanukitsiri; Jonathan Goldick; Brian DeForest; dl-Design Review
Cc: Narayan Venkat
Subject: RE: Kerberos functional spec

Thanks. See my inline reply.

____________________________________________
From: Ron Bhanukitsiri=20
Sent: Tuesday, January 16, 2007 10:59 AM
To: Mary Li; Jonathan Goldick; Brian DeForest; dl-Design Review
Cc: Narayan Venkat; Ron Bhanukitsiri
Subject: RE: Kerberos functional spec

Thanks Mary for your feedback.  My response below in brown.

Ron B[ee]

_____________________________________________
From: Mary Li=20
Sent: Tuesday, January 16, 2007 10:33 AM
To: Jonathan Goldick; Brian DeForest; dl-Design Review
Cc: Narayan Venkat
Subject: RE: Kerberos functional spec

1.	Question about "2.3 Unmet Requirements", if we don't' support =
Kerberos authentication for accessing files over cifs in the first =
release, Can customer use the application that requires Kerberos =
authentication only (no negotiation to NTLM)?

RB> I don't quite understand your question.  We don't support Kerberos =
application in a generic sense.
If the Windows (or Samba) client is joined to the Windows Active =
Directory domain (i.e. Kerberos), then
ONstor will tell the client we support Kerberos and if the client is =
Kerberos capable (i.e. W2K, W2K3, WXP, Samba 3-x client configured to =
use kerberos),
then the user will be authenticated via Kerberos.  However, if the =
client doesn't support Kerberos for some
reason (eg. not joined to the domain), we must support NTLM for backward =
compatibility and the user
will obviously be challenge for the password.  Otherwise, the user on a =
client not joined to the domain will
be denied service even if he/she has the right credential :-).
[Mary] Some application (Like IIS 6.00) can be configured to take =
Kerberos authentication only, even client is ok to negotiate down to =
NTLM. If we don't support kerberso  auth for accessing files over cifs,  =
is there any potential issue here? Could you explain more about "not =
supporting Keberos authentication for accessing files over cifs "?
RB> I think you misunderstood me.  We *are* going to support Kerberos =
over cifs.  In fact, the Kerberos
security blob is be carried inside the SessionSetupAndX SMBs.  This is =
what I explained earlier.
We could design it so that customer can configure ONstor to support only =
Kerberos if this is desirable.
But by default we will support both Kerberos and NTLM for backward =
compatibility.

2.	Do we support single sign-on? For example, if there are 3 Onstor =
virtual servers sharing the same KDC, user authenticated vsvr1 , does =
user still  need to type in password and user id for accessing vsvr2 and =
vsvr3 from the same client. Single sign-on is the major advantage for =
using Kerberos authentication.

RB> Ah "single sign-on" is such a popular terms these days and =
encompasses many aspects.
Our product will focus on the file service aspect of single sign-on.  =
What this means is that in
your scenario, if vsrv1 and vsr2 and vsr3 are all joined to the same =
Windows Active Directory
Domain, then the user will not need to type in the password or the user =
id.

3.	Do we support cifs session setup with "user@realm" format? For =
example user1@matrix.lab
=09
RB> Realm is a Kerberos terminology.  So in the Windows and Kerberos =
world, realm and fully
qualified DNS Domain name is synonymous.  The user@realm is called =
Kerberos principal and
for this particular case, it's a fancy name for a user :-).  However, a =
Kerberos principal does not
need to be a user (eg. vsrvr1@matrix.lab is the principal name for a =
server).
[Mary]  This is great news.  Just lbe aware that all authentication =
related components need to support this format. For example Idmapping =
for multiprotocol.

2.3	 Unmet Requirements
The following requirements are at risk for the initial CIFS release due =
to time-to-market considerations.

*	REQUIREMENT: Provide Kerberos v5 based authentication for clients =
accessing files over CIFS

Note:  This capability must be delivered without the usage of Samba =
libraries.  We need to purge Samba libraries post haste


_____________________________________________
From: Brian DeForest=20
Sent: Thursday, January 11, 2007 5:49 PM
To: dl-Design Review
Cc: Narayan Venkat
Subject: Kerberos functional spec

 << File: KerberosFuncSpec.doc >>=20


------_=_NextPart_001_01C73A5C.7BDD1798
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7650.28">
<TITLE>RE: Kerberos functional spec</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=3D2>Few suggestion<BR>
<BR>
1. can we have specific CLI to allow diag user to disable KRB =
authentication only. So that in case of error scenarios, the filer can =
be switched back to support NTLMv2 only auth.<BR>
<BR>
2. unix/linux KDC ?<BR>
AFAIK there is no unix/linux KDC. Do you mean MIT KDC server ?<BR>
These may be used in mixed scenarios having both unix and windows =
pcs<BR>
<BR>
<BR>
<BR>
<BR>
Also a pointer ,<BR>
single sign-on is supported by KRB5 by using credential forwarding. So =
it should work.<BR>
<BR>
<BR>
<BR>
3. Will filer login also be supported for KRB ?<BR>
<BR>
-jes<BR>
<BR>
-----Original Message-----<BR>
From: Ron Bhanukitsiri<BR>
Sent: Tue 1/16/2007 11:20 AM<BR>
To: Mary Li; Jonathan Goldick; Brian DeForest; dl-Design Review<BR>
Cc: Narayan Venkat; Ron Bhanukitsiri<BR>
Subject: RE: Kerberos functional spec<BR>
<BR>
Thanks Mary.<BR>
<BR>
_____________________________________________<BR>
From: Mary Li<BR>
Sent: Tuesday, January 16, 2007 11:15 AM<BR>
To: Ron Bhanukitsiri; Jonathan Goldick; Brian DeForest; dl-Design =
Review<BR>
Cc: Narayan Venkat<BR>
Subject: RE: Kerberos functional spec<BR>
<BR>
Thanks. See my inline reply.<BR>
<BR>
____________________________________________<BR>
From: Ron Bhanukitsiri<BR>
Sent: Tuesday, January 16, 2007 10:59 AM<BR>
To: Mary Li; Jonathan Goldick; Brian DeForest; dl-Design Review<BR>
Cc: Narayan Venkat; Ron Bhanukitsiri<BR>
Subject: RE: Kerberos functional spec<BR>
<BR>
Thanks Mary for your feedback.&nbsp; My response below in brown.<BR>
<BR>
Ron B[ee]<BR>
<BR>
_____________________________________________<BR>
From: Mary Li<BR>
Sent: Tuesday, January 16, 2007 10:33 AM<BR>
To: Jonathan Goldick; Brian DeForest; dl-Design Review<BR>
Cc: Narayan Venkat<BR>
Subject: RE: Kerberos functional spec<BR>
<BR>
1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Question about &quot;2.3 Unmet =
Requirements&quot;, if we don't' support Kerberos authentication for =
accessing files over cifs in the first release, Can customer use the =
application that requires Kerberos authentication only (no negotiation =
to NTLM)?<BR>
<BR>
RB&gt; I don't quite understand your question.&nbsp; We don't support =
Kerberos application in a generic sense.<BR>
If the Windows (or Samba) client is joined to the Windows Active =
Directory domain (i.e. Kerberos), then<BR>
ONstor will tell the client we support Kerberos and if the client is =
Kerberos capable (i.e. W2K, W2K3, WXP, Samba 3-x client configured to =
use kerberos),<BR>
then the user will be authenticated via Kerberos.&nbsp; However, if the =
client doesn't support Kerberos for some<BR>
reason (eg. not joined to the domain), we must support NTLM for backward =
compatibility and the user<BR>
will obviously be challenge for the password.&nbsp; Otherwise, the user =
on a client not joined to the domain will<BR>
be denied service even if he/she has the right credential :-).<BR>
[Mary] Some application (Like IIS 6.00) can be configured to take =
Kerberos authentication only, even client is ok to negotiate down to =
NTLM. If we don't support kerberso&nbsp; auth for accessing files over =
cifs,&nbsp; is there any potential issue here? Could you explain more =
about &quot;not supporting Keberos authentication for accessing files =
over cifs &quot;?<BR>
RB&gt; I think you misunderstood me.&nbsp; We *are* going to support =
Kerberos over cifs.&nbsp; In fact, the Kerberos<BR>
security blob is be carried inside the SessionSetupAndX SMBs.&nbsp; This =
is what I explained earlier.<BR>
We could design it so that customer can configure ONstor to support only =
Kerberos if this is desirable.<BR>
But by default we will support both Kerberos and NTLM for backward =
compatibility.<BR>
<BR>
2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Do we support single sign-on? For =
example, if there are 3 Onstor virtual servers sharing the same KDC, =
user authenticated vsvr1 , does user still&nbsp; need to type in =
password and user id for accessing vsvr2 and vsvr3 from the same client. =
Single sign-on is the major advantage for using Kerberos =
authentication.<BR>
<BR>
RB&gt; Ah &quot;single sign-on&quot; is such a popular terms these days =
and encompasses many aspects.<BR>
Our product will focus on the file service aspect of single =
sign-on.&nbsp; What this means is that in<BR>
your scenario, if vsrv1 and vsr2 and vsr3 are all joined to the same =
Windows Active Directory<BR>
Domain, then the user will not need to type in the password or the user =
id.<BR>
<BR>
3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Do we support cifs session setup with =
&quot;user@realm&quot; format? For example user1@matrix.lab<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
RB&gt; Realm is a Kerberos terminology.&nbsp; So in the Windows and =
Kerberos world, realm and fully<BR>
qualified DNS Domain name is synonymous.&nbsp; The user@realm is called =
Kerberos principal and<BR>
for this particular case, it's a fancy name for a user :-).&nbsp; =
However, a Kerberos principal does not<BR>
need to be a user (eg. vsrvr1@matrix.lab is the principal name for a =
server).<BR>
[Mary]&nbsp; This is great news.&nbsp; Just lbe aware that all =
authentication related components need to support this format. For =
example Idmapping for multiprotocol.<BR>
<BR>
2.3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Unmet Requirements<BR>
The following requirements are at risk for the initial CIFS release due =
to time-to-market considerations.<BR>
<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; REQUIREMENT: Provide Kerberos v5 =
based authentication for clients accessing files over CIFS<BR>
<BR>
Note:&nbsp; This capability must be delivered without the usage of Samba =
libraries.&nbsp; We need to purge Samba libraries post haste<BR>
<BR>
<BR>
_____________________________________________<BR>
From: Brian DeForest<BR>
Sent: Thursday, January 11, 2007 5:49 PM<BR>
To: dl-Design Review<BR>
Cc: Narayan Venkat<BR>
Subject: Kerberos functional spec<BR>
<BR>
&nbsp;&lt;&lt; File: KerberosFuncSpec.doc &gt;&gt;<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C73A5C.7BDD1798--
